REMARKS 



The above amendment and these remarks are responsive to 
the Office Action of Examiner Baoquoc N. To, mailed 19 Apr 
2004. 

Claims 1-37 are in the case, none as yet allowed. 

Response to Arguments 

Applicants have been instructed to submit an argument 
under the heading "Remarks" , pointing out disagreements with 
the Examiner's contentions, and discuss the references 
applied against the claims, explaining how the claims avoid 
the references or distinguish from them. 

Applicants call to the attention of the Examiner the 
material in the previous Response at pages 20 to 23 for just 
such an argument and explanation with respect to Rail et al . 
(U.S. Patent 5,680,611, hereinafter, Rail) For the 
convenience of the Examiner, this material will be restated 
below in connection with the current Office Action, and 

END920000156US1 20 S/N 09/832,572 



expanded upon in view of the new art reference, Schweitzer 
et al . (U.S. Patent 5,680,611, hereinafter Schweitzer). 

Claim Objections 

Claims 7 and 2 9 have been objected to for the use of 
duplicate words "on flagged" . 

The Examiner is correct, and applicants have amended 
the claims as suggested. 

35 U.S.C. 103 

Claim 1-37 have been rejected under 35 U.S.C. 103(a) 
over Rail, et al . , U.S. Patent 5,680,611. 

In this rejection (based only on Rail) , the Examiner 
applies the art to claims 1-6, 26-27 and 36. Applicants 
will discuss these claims with respect to Rail. The other 
claims are discussed with respect to Rail in view of 
Schweitzer. 
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Applicants traverse and argue that the Examiner has not 
established a prima facie case of obviousness • The legal 
basis for this traversal is set forth in greater detail in 
the prior Response, dated on or about 8 Oct 2003. 

With respect to claims 1-37, Rail describes a duplicate 
record detection system and method where a checksum is 
derived for selected fields of records, and the checksums of 
a selected record compared with checksums of a selected 
file. (Col. 4, lines 46-55). Rail relates to call detail 
records (CDRs) , records which are created when a telephone 
customer places a telephone call. These are not invoices, 
are not like invoices, and are not processed like 
applicants' invoices . 

With reference to claims 1, 26, and 36, Applicants 
traverse and argue that the Examiner has not established a 
prima facie case of obviousness. The legal basis for this 
traversal is set forth in greater detail in the prior 
Response, dated on or about 8 Oct 2003 . 

The Examiner characterizes the follow teaching of Rail 
as "replacing said another record, if found with said first 
record" (Office Action, page 3) : 
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"The method compares the generated checksum for the 
currently processed record with stored checksums in the 
selected check file at step 108. The small and fixed 
size of the generated and stored checksums allow the 
comparison step to utilize an efficient binary search 
technique. If no match is found, then the generated 
checksum is stored in the check file at step 110. In 
addition,, a unique transaction identifier may be stored 
with the generated checksum." (Rail, Col. 4, lines 34- 
41.) 

There is no teaching here of replacing records in a database 
having the same index number, as applicants claim: 

<* 

w . . . for each record having said index number, searching 
said database for another record, loaded during a 
second earlier time period, having the same index 
number and replacing said another record, if found, 
with said first record;..." (Claim 1, lines 5-9. See 
also claims 26 and 36) . 

There being no teaching of replacing records, Rail (at 
Col. 4, lines 40-52) cannot teach the concept of comparing 
each of the records loaded into the database "for which no 
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matching index number record was found with all the other 
records including the replaced records ..." (Claim 1, lines 
14-16) . For this teaching, the Examiner (Office Action, 
page 3) cites Rail at Col* 4, lines 46-52. Here Rail 
teaches : 

"If the generated checksum matches a stored checksum in 
the selected check file at step 108, then the 
transaction identifier of the current record and the 
transaction identifier associated with the matching 
stored checksum are compared at step 114. If the 
transaction identifiers do not match, then a duplicate 
has been identified and the record is stored in a 
duplicate file at step 116." 

With respect to claim 2, the Examiner refers to Rail at 
Col. 3, lines 5-10. Here Rail is describing billing records 
based on CDRs to be sent out as invoices to customers, not 
the processing of invoices received for payment. Further, 
claim 2 depends from claim 1, and is distinguished from Rail 
as previously described. 

With reference to claims 3 and 27, the Examiner asserts 
that Rail teaches applicants' "compact database", which is 
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maintained "by removing canceled invoice documents and 
invoice documents older than a predetermined period" . 
(Claim 3, lines 5-7). For this teaching the Examiner refers 
to Rail at Col. 3, lines 41-46, which states: 

"After a record is received for processing at step 100, 
key fields of the record are then selected for checksum 
processing at step 102, if appropriate or desired. 
Selecting a few key fields from an entire record 
reduces the amount of data processed and stored during 
checksum processing . " 

The "compact database" is maintained in Rail by "selecting a 
few key fields", not by "removing canceled invoice documents 
and invoice documents older than a predetermined period", as 
in applicants' claims 6 and 27. 

Applicants have canceled claims 3-5 and rewritten claim 
6 to include their limitations. 

With respect to claim 4, which by this amendment has 
been incorporated in claim 6, the Examiner asserts that Rail 
teaches entry of invoice data from a plurality of accounts 
payable systems at Col. 3, lines 1-2, (Office Action, page 
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5.) This is what Rail teaches: 

"Check files 30 may store checksums of CDRs for the 
past three months or more, depending on storage 
capabilities, the likelihood of receiving latent 
duplicant records, and other factors," (Rail, Col. 2, 
line 66 to col. 3, line 2.) 

There is no teaching here of entering invoice data from a 
plurality of accounts payable systems. CDRs are call detail 
records (Rail, Col. 2, lines 6-7), and while these may be 
entered from various sources, they are not accounts payable 
systems . 

With respect to claim 5, which by this amendment has 
been incorporated in claim 6, the Examiner asserts that Rail 
teaches entering invoices into a compact database for 
payment at a later data (sic, date), and references Col 3, 
lines 45-50. This is what Rail teaches: 

"Using the example of CDR processing in FIG. 1, a 
complete CDR may occupy four thousand bytes or more of 
storage space, whereas selected key fields may occupy 
one hundred bytes or less." (Rail, Col. 3, lines 45- 
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50.) 



There is no teaching here of entering invoices for payment 
later. Rail is discussing the generation of invoices to be 
sent out, not the processing of invoices to be paid. 

With respect to claim 6, the Examiner asserts "Rail 
teaches the step responsive to submission of an invoice with 
a null invoice indicia field of entering data indicia in 
said null invoice indicia field." (Rail, col, 3, lines 53- 
55) . 

This is what Rail teaches: 

tt Using the selected key fields of the record, the 
method generates a checksum at step 104." (Rail, Col. 
3, lines 54-55) . 

This is what applicants claim: 

"...responsive to submission of an invoice with a null 
invoice indicia field entering date indicia in said 
null invoice indicia field..." (Applicants' claim 6). 
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The Examiner refers to "data" indicia (presumably the 
check sum), and applicants claim Mate" indicia, which is 
not a check sum. In either event, Rail doesn't teach what 
applicants claim. 

Claims "7-25, 27-35 and 37 have been rejected under 35 
U.S.C. 103(a) over Rail in view of Schweitzer. 

With reference to claims 7, 28-29 and 37, applicants 
have amended claims 7, 28, 29 and 37 to further describe the 
process of applicants' invention, as that is taught in their 
specification with respect to Figure 2 at Page 10 line 11 to 
Page 15 line 15. 

With reference to base claims 7, 28-29 and 37, and 
their respective dependent claims 8-25 and 30-35, applicants 
previously amended the claims to specify the specific 
reports generated from the packets. These are the reports 
set forth in Figure 3 and summarized in the specification at 
page 24, lines 5-11, which are fed to analysts for further 
processing. Rail does not teach the generation of such 
reports. The Examiner states: 

"Rail does not explicitly teach generating from said 
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current invoices and said history invoices a packet of 
invoices... and generating from a plurality of said 
packets [several reports recited in claims 7 and 29] . 
(See Office Action, page 6) . 

And then asserts: 

"However, Rail . . . teaches the comparison of current 
record (invoice not yet been paid) and stored checksum 
(history invoices) to identify the duplicate, and if it 
si not duplicate then the currently (sic) invoice is 
stored in the master file (packet) . (Office Action, 
page 6) . 

And continues, referring to Schweitzer: 

"...Schweitzer teaches ^removing the duplicate records 
from the central database 175* (fig. 5) and ^customized 
reporting with built-in-report generation or an NSPs 
choice of off-the-shelf graphical reporting packages' 
(col. 4, lines 17-18) 

Applicants traverse. This characterization of the 
teachings of Rail and Schweitzer relies on applicants' own 
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claims. The specific reports the claims recite are not 
taught by either Schweitzer or Rail. Nor is the claimed 
generation of packets from which those reports are derived 
taught or suggested by either reference. 

Claims 8-25 depend from claim 7, and claims 30-35 
depend from claim 29, the base claims having been amended to 
recite further details of the generation of packets not 
taught by either Rail or Schweitzer. 

Applicants urge that claims 1-37 be allowed. 

SUMMARY AND CONCLUSION 

Applicants urge that the above amendments be entered 
and the case passed to issue with claims 1-37. 

The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one /more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in accordance with M.P.E.P. 
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Sections 707.02 (j) and 707.03 in order that allowable claims 
can be presented, thereby placing the Application in 
condition for allowance without further proceedings being 
necessary. 



Date: 18 Jun 2004 

Shelley M Beckstrand, P.C. 
Attorney at Law 
314 Main Street 
Owego, NY 13827 

Phone: (607) 687-9913 
Fax: (607) 687-7848 



Sincerely, 



W, D. Calkins, et al. 



By 
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